Fix packet flood caused by dead scale/color dirty-check - #76

Problem

sendScale() and sendColor() compare the current value against the last one
sent, but never store the new value. setLastScale() and setLastColor() have
no call sites anywhere in the repository — only their four declarations. So
lastScale stays at its initial -1.0f and lastColor stays null forever,
every comparison fails, and the 20 ms task re-sends identical data indefinitely.

Measured on a production Paper + Geyser/Floodgate + ModelEngine server, 52
models visible to 2 Bedrock players, over a 12.2 s capture of geyserutils:main:

Traffic composition: scale=1.0 47,511 (49.7%), color=-1 45,192 (47.3%).

Control within the same capture: animation properties go through
lastIntSet, a cache that is written. They produced 342 packets in the same
12 seconds, against 92,703 for scale/color. Same plugin, same window, 271×
difference — this isolates the cause to the dead dirty-check rather than to
network conditions, Geyser, or entity count.

Cost scales linearly in both entities and Bedrock viewers, and there is no
config workaround: the 20 ms period is hardcoded.

Changes

The flood

ModelEnginePropertyHandler — store the value after sending. getEntityTask()
on ModelEngineEntityData is already covariant, so no cast is needed.

BetterModelPropertyHandler — three separate issues on this path:

• sendScale() had no dirty-check at all (the lastScale parameter was unused)
  and no players.isEmpty() guard.
• sendColor() had the condition inverted: if (firstSend) applied the check
  only on the first send — where it should be forced — and never on the periodic
  loop. It now matches the ModelEngine path.
• setHurt(false) moved to where the tint is read, from after the send loop.
  This is required, not cosmetic: with the dirty-check active the early return
  would otherwise never consume the flag and the model would stay tinted forever.
  Consuming it at read time gives one tint packet and one clear packet per hit.

Periodic forced resync in both task handlers:

boolean forceSync = tick % 100 == 0;   // ~2 s

Without this the fix would remove an unintended safety net. The property
handshake runs exactly once per viewer: sendEntityData() is only reached from
sendSpawnPacket(), i.e. on viewer add, and CustomEntitySpawnSynchronizer
schedules the scale/color callback a single time after the spawn resend window.
On the Geyser side, CustomEntityDataPacket is dropped silently when
getEntityByJavaId() returns null (entity not registered yet) — no retry, no
log. Today the 50 Hz loop masks any such loss within 20 ms; without a
replacement there would be no recovery path and an affected model would render
at default scale until the viewer leaves and re-enters range. A 2 s forced
resync keeps that self-healing property at ~104 pkt/s on the capture above,
still a 75× reduction. Happy to make the interval configurable if preferred.

Async correctness and scheduling

Smaller and independent of the above, found while tracing the same code paths:

• BedrockMountControlRunnable was scheduled every 1 ms — 1000 executions
  per second on the same 4-thread pool that serves every per-entity task. It
  reads mount input from head pitch, which the client updates at 20 Hz. Now
  models.mount-control-period, default 50 ms.
• NPE: Bukkit.getPlayer(uuid) returns null for a player who is
  disconnecting, since the cache entry is only removed on PlayerQuitEvent.
  Skip null players.
• playerJoinedCache was an unsynchronized HashSet, written from the main
  thread on join/quit and iterated from the scheduler pool. Now
  ConcurrentHashMap.newKeySet(); the getter widens to Set<UUID>, which all
  four call sites already satisfy.
• Bukkit.getOnlinePlayers() was called from an async thread once per model
  per tick — ~2,600 scans/s at 52 models. The Bedrock player list is now built
  once per global update cycle in UpdateTaskRunnable and read from a
  volatile field, leaving checkViewers()'s signature unchanged. Trade-off:
  new viewers are picked up with up to one global cycle (35 ms) of latency.
• The 20 ms per-entity period is now models.entity-update-period, default
  20, so behaviour is unchanged for everyone but admins with many entities have
  a knob.

New config keys default to their current effective values, and ConfigManager
reads with an explicit default, so existing config.yml files keep working
untouched.

Expected result

On the captured workload: ~7,800 pkt/s → ~150 pkt/s — the ~104 pkt/s resync
floor, the 342 animation bundles (~28/s, already dirty-checked and unaffected by
this PR), and two packets per damage tick. Note that the 2,319 damage-tint
packets in the capture were themselves duplicates of a far smaller number of
actual hits, for the same reason as the rest of the flood.

Verification

The dead setters are visible in the source at
ModelEngineTaskHandler/BetterModelTaskHandler: lastScale and lastColor
are assigned in the constructor and in their own setters, and nowhere else.
grep -rn 'setLastScale\|setLastColor' --include='*.java' . returns the four
declarations and no call sites. The same holds on the released 1.0.9 jar:
putfield on either field appears only in <init> and in the setter, and there
is no invokevirtual to either setter.

The inverted condition in BetterModelPropertyHandler.sendColor() is visible
directly in the diff.

./gradlew :paper:compileJava passes.